Fritz: All Fritz

home *** CD-ROM | disk | FTP | other *** search

/ Fritz: All Fritz / All Fritz.zip / All Fritz / FILES / BUSINESS / MAKEDEMO.LZH / MDEM4B.EXE / MANUAL.TXT < prev next >

Wrap

Text File | 1992-10-28 | 71KB | 1,624 lines

M A K E D E M O ----------------- Version 4 ----------- U S E R ' S M A N U A L --------------------------- Last updated: October, 1992 _______________________________________________________________ | | | MakeDemo is NOT a public domain program. It is Copyright (c) | | 1989 - 1992 by WindhamWoods Publishing. All rights reserved. | |_______________________________________________________________| COPYRIGHT INFORMATION This software and accompanying documentation are protected by United States Copyright law and also by International Treaty provisions. Any use of this software in violation of Copyright law or the terms of LICENCE.DOC will be prosecuted to the best of our ability. The conditions under which you may copy this software and documentation is clearly outlined in LICENCE.DOC. Registered users may install MakeDemo on a computer attached to a network, or remove it from one computer and install it on another, provided that the copy will not be used by more users than the number for which it was licensed. As a registered user, you may distribute any file which you create in part or in whole with this software. Further, you may include any screen(s) that you received with the MakeDemo distribution as part of your own presentation(s). Licensee shall not use, copy, rent, lease, sell, modify, decompile, disassemble, otherwise reverse engineer, or transfer the licensed program except as provided in this agreement. Any such unauthorized use shall result in immediate and automatic termination of this license. Where differences exist between the foregoing information and that contained in "LICENCE.DOC," the latter shall govern. ASP Information _______ ____|__ | (R) --| | |------------------- | ____|__ | Association of | | |_| Shareware |__| o | Professionals -----| | |--------------------- |___|___| MEMBER "This program is produced by a member of the Association of Shareware Professionals (ASP). ASP wants to make sure that the shareware principle works for you. If you are unable to resolve a shareware-related problem with an ASP member by contacting the member directly, ASP may be able to help. The ASP Ombudsman can help you resolve a dispute or problem with an ASP member, but does not provide technical support for members' products. Please write to the ASP Ombudsman at 545 Grover Road, Muskegon, MI 49442 or send a CompuServe message via CompuServe Mail to ASP Ombudsman 70007,3536." Table of Contents a. Copyright Information I. Introduction II. The Files of MakeDemo III. Installation IV. Starting Up MakeDemo V. What MSHOW looks for in your Creation Menus Predefined System Menu Selections Code Those Screens Menu Mechanics Types of Screens Prompt Screen Be Mouse Ready VI. Creating a Presentation with MDEMO MDEMO Features Using a Mouse Large Fonts Overlays, the Key to Presentation Effects Screen Test Viewing a Work-In-Process VII. Making Single .EXE File Presentations Branding (Optional) VIII. MLITE, The MakeDemo Stripped Down Runtime IX. MDEMO Quick Reference X. Customer Support _______________ I. Introduction MDEMO, for creating, and its companion MSHOW, for viewing a presentation, together comprise the MakeDemo system that gives you the ability to present information on a PC or compatible computer of almost any persuasion, color or monochrome. And then there is MLITE, a stripped down version of MSHOW with some limitations on features but worth the trade-off where disk space is a premium. See section VIII for the differences. MakeDemo's architecture promotes o presenting information in as many as 2000 screens that include your own menus and sub-menus, as you define them and may also include DOS level commands and executibles and/or shellintg out to DOS. o small files: a typical 100 screen self-contained presentation consumes 120 kBytes: great for downloading over BBSs. o small memory usage: less than 80 kBytes of RAM, less memory intensive than many TSR applications. o your own user interface design: you design all screens including prompt screens, context sensitive help, etc. o language independence: your client sees only what you create. There are no hard coded screens or messages that pop up in your presentations. First, there's MSHOW.EXE. By itself it does nothing: rather it reads an external or appended 'resource file'. Think of MSHOW as a library of functions that can interpret your 'presentation' that you create with MDEMO. Second, there's MDEMO.EXE, used to create presentations to be displayed by MSHOW.EXE, either separately or combined with a presentation to form a single EXE file. MakeDemo gives the novice through expert user the ability to create slide show type presentations with sound effects, various screen overlaying techniques, and various delays with interactive menuing and mouse support. MakeDemo includes tools to put full presentation into a single .EXE file complete with "F1 - Help" and your own order form: no extra file listing each screen for a presentation or a script language to learn if you want to include menus. MakeDemo is to screens what a good word processor is to paragraphs. Think of MakeDemo as a text organizer for files of screens, not paragraphs. As you work on a creation, add screens, insert blank screens, import text in 25 line chunks from ASCII files, screens captured from other software, or other MakeDemo files, in part or in whole. Then edit one screen at a time, move segments around or copy segments to "place" on other screens. Make copies of screens. Delete screens. Save groups of screens to new files. Sounds like a word processor: except that you scroll through a file screen by screen rather than line by line. All with mouse support. But MakeDemo is more. Give your users control in how to view presentations. Simulate menu driven software for very realistic demos. Create a hypertext sort of system for quickly moving through a large presentation, such as a catalog or book on disk. Use MakeDemo to create your own menuing system for DOS which additionally includes detail screens about a DOS program that is available for calling. Or use the extra screens to provide a little training about the program in question. Manually override color/monochrome display formatting. Now, when a "color display" is not strictly a color display, switch over instantly without first exiting to DOS, typing in some modifying commands, and then restarting the presentation all over again. In fact, view a presentation in process being created in color, as it would appear on a monochrome display. Choose from many large fonts when creating outstanding screens. Create boxes with automatic correction for crossing lines. Customize your own or add to selection of boxes and fonts with almost any ASCII text editor. PLEASE NOTE - Only one version of MakeDemo exists for both shareware and registered use. Without the correct validation code, MDEMO comes up in the 'shareware' mode. You need to register your use of MakeDemo in order to receive your assigned validation code in order to bypass the 'shareware' mode. Both MDEMO and MSHOW have identical and integral WindhamWoods Publishing 'shareware' screens that appear when certain conditions are detected. Similarly, MLITE produces a single line "reminder." Shareware Users: The 'shareware' screens appear if - 1. You run MDEMO from the command line and do not include the correct validation code. 2. You start MSHOW or MLITE to view a presentation either with no file specified at all, or with a presentation file specified on the command line (or integrated into a single .EXE file) created, or last edited, with an unregistered version of MDEMO. In all cases, whenever the 'shareware' screen appears, pressing any key erases that screen and lets you continue, unheeded. Registered Users: The serial number for your copy of MakeDemo is located on the 2nd line of the file MDEMO.WWP. Upon start-up, MDEMO reads that number and imbeds it and the validation code that was included on the command line with MDEMO into any presentation file that is edited or created. As a registered user, make sure that the serial number is yours. The validation code will only work with it to circumvent any WindhamWoods 'shareware' screens from appearing. _________________________ II. The Files of MakeDemo MakeDemo is supplied in three self-extracting files listed below. Not only does packing MakeDemo into three files take about half the disk space, installing MakeDemo on your system is also easier. Packed into each is the same PACKING.LST file that completely lists all of the individual MakeDemo files. The following is a brief description of the three files. While each can stand alone in its own right, all three contain files necessary to successfully produce a MakeDemo presentation. For detailed information on installing MakeDemo on your system, please read section III - Installation. MDEM4A.ZIP Overview of MakeDemo .EXE Contains the necessary files to produce a single .EXE executable file, DEMO.EXE from WATCH_ME.1ST created with MakeDemo. The resulting file with about 55 screens is a fully functioning sales pitch for MakeDemo. MDEM3B.ZIP A More Elaborate Presentation .EXE This time you can create a single file presentation of MakeDemo's "help" facility. With about 200 screens, this presentation also created with MakeDemo is a more elaborate example of MakeDemo's capabilities. And this archive also contains the MakeDemo manual. MDEM4B.ZIP MakeDemo Files .EXE Contains MDEMO.EXE and the ancillary utilities such as the screen capture utility for those who are ready to start creating their own presentations. Also included are the various .DOC files that complete the MakeDemo package. And for those who would like a bare-bones MakeDemo runtime, there's MLITE.EXE, great for a "shareware" front end to your own programs. _________________ III. Installation MakeDemo was designed to be accessed from its own directory. Therefore, you should place all the files supplied with MakeDemo in its own directory and include that directory in the PATH statement of your AUTOEXEC.BAT file. IMPORTANT NOTE: Be sure to reboot your computer after modifying your AUTOEXEC.BAT file. If you need help in this area, consult someone knowledgeable in the workings of DOS. MakeDemo as supplied in three self-extracting files is ready for "unpacking" and placing on your hard disk (preferable) or other floppy disk. The full complement of files takes about 500 kBytes of disk space plus 250 k Bytes for the example files you'll be creating as you get started. As part of the unpacking process, you can declare a destination directory that doesn't as yet exist, in which case it will first be created automatically and the files unpacked to it. Where the directory already exists and the files of an older version of MakeDemo reside in it, you will be prompted before overwriting an existing file of the same name, to which you should answer "yes." HARD DISK INSTALLATION Simply place the disk in the A drive and type MDEM4A C:\MDEMO and press <Enter>. in like manner type MDEM4B C:\MDEMO and <Enter>. in like manner type MDEM4C C:\MDEMO and <Enter>. Once you have included the MakeDemo files in its own directory and have included that directory in the "PATH," you can then call up MakeDemo from within any other directory. There's no need to keep multiple copies of a file and then inadvertently loose track of the current one. FLOPPY DISK INSTALLATION Use of MakeDemo on a computer without a hard disk is not recommended. The following information is provided for those hearty souls who persist in overcoming self imposed limitations. You need to format four disks before continuing. Simply place the master disk in the A drive, one of the formatted disks in drive B, and type MDEM4A B: and press <Enter>. When completed, label disk "MSHOW." in like manner type, place another formatted disk in drive B and type MDEM4B B: and <Enter>. When completed, label disk "HELP." in like manner type, place another formatted disk in drive B and type MDEM4B C: and <Enter>. When completed, label disk "DOCS." The fourth disk holds the files for creating and viewing a presentation. Place the fourth disk in drive A and the "DOCS" disk in drive B and type COPY B:MDEMO.EXE A: COPY B:*.WWP A: Replace the disk in drive B with the "HELP" disk and type COPY B:MDEMO.HLP A: Replace the disk in drive B with the "MSHOW" disk and type COPY B:MSHOW.EXE A: When completed, label disk "MDEMO." ________________________ IV. Starting up MakeDemo Let's start by making an executable of the MakeDemo "help" system, just as you might do yourself. All the DOS machine instructions are contained in the DEMO.BAT file, all ready to run. The MDEMO.HLP file and MSHOW.EXE are combined to form M_HELP.EXE. The first time you run this program, you'll see the 1st screen of the "Help" file, a menu screen, AND you will see disk activity while your computer crunches away creating an index of all the screens in the "Help" file. The time it takes to complete this chore depends upon the type machine you are using. You can use the presentation while the indexing continues in the background, but response will be sluggish. It's best to wait until the process is completed before trying to maneuver through the file. Once the index is created, subsequent viewing will start almost immediately: the index, stored to disk is not recreated, but is automatically read from disk into memory, a much faster operation. As a registered user, you received a validation code. If you wish to use MakeDemo and bypass the "Shareware" screens, you must include your validation code on the command line when calling up MakeDemo. NOTE: If you have installed MakeDemo on your hard disk in its own directory, and have included its directory in the "PATH" statement of your AUTOEXEC.BAT file and then rebooted, you're all set to change directory to any other and call up MakeDemo. If, on the other hand, you are using a dual floppy system, place your MDEMO disk, the fourth one you created in the unpacking process, in drive A and a preformatted disk in drive B. At the DOS prompt type PATH=A:\. Then log onto drive B and you're ready to call up MakeDemo. For example, if your validation code is SK1234, you would type MDEMO SK1234 and <Enter>. Remember, that code is uniquely yours. Giving it to someone else along with the program really isn't much of a gift. After all, the "shareware" screens aren't really that obnoxious. But violating the copyright laws deprives the authors of MakeDemo from receiving fair value for value rendered. If you have any questions once you have called up MakeDemo you can press F1 to see the "Help" categories from which to select more detailed help. There's a lot of information in this help file. It is in itself a MakeDemo creation, similar to something which you yourself might wish to create. To quickly get up to speed as to what makes a great presentation, use MDEMO itself to "Edit" the help file. There's no need to make any changes to the file. Just go through the screens and see how the menus are defined and what "appearance" options have been selected. Dissect it, take it apart. That's right -- go into MakeDemo and edit them and see some of the behind-the-scenes stuff. MDEMO is just the editor, if you will; MSHOW, the presenter. We can talk a lot about interactive menus, but a picture is worth a thousand words, so to speak. To "Edit" the help file, select for the working directory that which contains the MakeDemo files, normally the MDEMO directory. At the DOS prompt type MDEMO and the validation code, if you are a registered user, and press <Enter>. When the menu appears across the bottom of the screen, select "Files," highlight the help file, "MDEMO.HLP," and press <Enter>. Up will pop the first screen of the file. Now to see more of the screens, use the down and up arrows to move through the file, observing how the menus are constructed. For now, just observe. The details follow a little later in this document. Select "More" to get the other half of the main menu and select "Appearance" to see what methods were selected for the screen that is shown. Press <Esc> to move through the three appearance menus so as not to disturb the choices already selected. When you're finished, press <Escape> and follow the directions. _________________________________________________________________ V. What Gives MSHOW a Clue as to What, Where, and How to Present You need not be a 'programmer' in the old sense of the word in order to create a masterpiece. Knowing one's way around a word processor is qualification enough. To create an MSHOW 'presentation' requires following a few simple rules, which we will get to shortly. MSHOW interprets your presentation or resource file. There are just a few rules that impact how you go about its design. Your presentation or resource file is nothing more than a series of screens that describe to MSHOW your application. All the unique information is placed on the screens themselves. Upon presentation, this 'coding' information is blanked out. Upon startup, MSHOW almost immediately puts up the first screen, but then continues to 'index' the remaining screens in the background until completed. Indexing performs a number of functions. MSHOW creates a list, by name, of all screens in memory. MSHOW lets you include 'menus' in your document that uses this index of screen names. A menu is a list of choices, or screens, from which your user can select to view next. Hence, only screens that must be referenced need a unique name. MSHOW saves this index to disk in a file of the same name, but with the ".INX" extension. When preparing to display a presentation MSHOW first looks to see if the index file exists on disk. If it is found and its date/time stamp is more recent than that of the presentation file itself, MSHOW reads it into memory. Once created, this feature is a real time saver, especially on slower systems. The index file is in reality an ASCII text file. It can be printed out using the DOS TYPE command. The name and length of each screen is stored sequentially, each separated by commas. You might want to refer to this file created by your own presentation in order to eliminate conflicts in screen names. You may also "code" your creation to become a self-running presentation of sorts. If you wish to let your users view your document as a presentation (ie. automatically present screens in menu order at pre-programmed intervals) and automatically recycle indefinitely, or until <Esc> is pressed, give your viewer access to the presentation options. (see the system menu options) Menus: There is an optional system menu screen and then there are the menus that are part of information you are presenting. The system menu, or virtual menu, has the rudimentary selections such as <F1>, <Esc>, <PgUp>, <PgDn>, and <Tab> always active, regardless of whether or not you assign additional keys to them or not. More about that later. These selections are always active whether or not they can be seen on the screen. This menu, if you have defined your own, is always as close as the <Tab> key or by moving the mouse to one of the screen edges. There are reserved names for these screens which MSHOW looks for upon startup. MSHOW looks for one and only one screen with one of these names LSIDE0 TSIDE0 BSIDE0 RSIDE0 PLEASE NOTE: These names are reserved and are not to be used for any other purpose. If you do by chance try to include them in your own menu, strange things will happen and the results will be something less than acceptable. The architecture of MSHOW allows, even encourages, you to design this system menu screen to your own taste. Of course, feel free to use whatever screens you like of those supplied with MakeDemo. If you like, modify them with your own context sensitive "Help". Predefined System Menu Choices: There are a number of predefined functions which your system menu may or may not include. That's up to you. For example, to give your viewer the ability to shell out to DOS, you must include the appropriate selection on the system menu screen. Certain names are 'reserved' and if used, MSHOW expects conformance to the appropriate schema. We'll get into this schema later, but in the interests of being concise, all the information you will need for referral purposes is included here in one place. Those menu selections are Hard- Soft- Coded Coded Actions Performed Keys Functions ----------------------------------------------------------------- <Esc> QUIT returns the user to the previous menu, or out to DOS, whichever comes first. In the AUTO presentation mode, discussed below, the first press of <Esc> puts MSHOW into the SOUND mode, discussed below. <PgDn> PAGEDN causes the next screen to appear provided screen has no name. A name of "+" or "-" is permitted where a repeating presentation is desired. <PgUp> PAGEUP causes the previous screen to appear provided the present screen has no name. A name of "+" or "-" is permitted where a repeating presentation is desired. <Tab> TAB causes MSHOW to search all screens stopping at the first with the name "_SIDE0". The "_" represents the characters "R", "T", "B", or "L". When using a mouse, MSHOW can differentiate between the various options, but without the mouse, MSHOW has no clue as to what the first letter might be. Only one system menu screens is permitted. <F1> HLLP You can provide a sequence of screens as a general "Help" facility. These might be of a more general nature, explaining the typical maneuvers to progress through a presentation. When a system menu screen is being presented, either by pressing the <Tab> key or moving the mouse to an edge, MSHOW presents the first overlay it finds on the screen. (Hopefully it is the system menu.) All other screen segments on that screen only appear when F1 is pressed. (See section on screen overlays. POFRM Use this name to define a sequence of screens, such as a Purchase Order Form, that can be accessed from the system menu and or associated "hot" key. Of course, you can name your order form something different and give access to it from your own menu. PRIN This key word tells MSHOW to retrace to beginning of a menu selection or order form and send all the pertinent screens to the printer. You have the option of including a "prompt" screen, discussed further on, to give the user the opportunity of aborting the process before actually starting the print operation. If the "prompt" screen does not exist in your file, MSHOW sends the form to the printer, by default. A screen is a chunk of 25 lines each. If you want to print a form on a single sheet of paper of 60 lines, you are not limited to 2 screens. To prevent particular lines from going to the printer, merely place an <Alt>13 symbol at the beginning of that line on the screen. MSHOW ignores it and skips to the next line. SHELL Give your users the ability to interrupt viewing a presentation so as to temporarily go to DOS for doing something else, and then return to the application without losing a step. COLOR MSHOW detects whether the system is configured with a monochrome or color monitor. In those cases where the user might not be happy with the default, include this ability to switch. FFUNC reserved, but not used. RSVD reserved, but not used. R e s e r v e d f o r P r o m p t S c r e e n O n l y ------------------------------------------------------------- YES NO P r e s e n t a t i o n O p t i o n s --------------------------------------- N_EFFECT No sound or graphics effects EFFECT Graphics Effects such as overlay sliding, etc. SOUND Same as above, but includes preset sound effects AUTO Self running presentation with programmed delays As part of your presentation, you have the ability to include your own menus that allow the user to move through a file in response to your defined menu selections. One group of screens might explain certain features of your system, another might be your order form. You can design menus with up to 30 selections on a single screen, sub-menus up to fifty deep, with a total of 2000 screens in one file. Think of it as sort of a hypertext application. Code Those Screens: There is very little specific coding information that MSHOW needs to access. MSHOW is designed to do quite a lot on very little information. MSHOW does need to be able to discover the names you give to the first screen of a screen sequence. All these pieces of information are imbedded in lines starting with either , or ( ie. <Alt> 4 or <Alt> 6 respectively.) These characters are keyboard accessible by simultaneously pressing the <Alt> key and the appropriate number key on the numeric keypad. Lines prefixed with either of these symbols can up to 80 characters long and must appear within the top 6 lines of a screen. If one line is insufficient, use additional lines, provided each starts with the appropriate symbol followed by a comma. The name following either of the first two symbols can only appear once, if at all, on a screen. Generally speaking, the characters following these symbols mean - ( <Alt+4> ) screen name and menu selections ( if any. ) ( <Alt+6> ) designates the place on the screen where, just to the right, the menu selection. The area of the screen can have multiple lines but can not exceed 256 character spaces. (For example, 8 rows by 32 columns.) MSHOW uses the color attribute of the area to delineates it from that of the surrounding area. Let's take a closer look at the attribute. This is an important point. MSHOW defines the width of a field by looking for a background color change as it moves from left to right after finding the beginning of the selection or field. The foreground color (the printed characters) can differ along the line but not the background color. When MSHOW detects a change, it calculates the width. MSHOW then travels down the screen in this last column looking for any change in foreground and background colors. When found, MSHOW calculates the height of the menu selection. This is important. You can place menu selections on adjacent rows using the same background / foreground colors. You ask "How can that be?" By using a different foreground color for the last character (usually hiden as a space where the different foreground color doesn't show.) Because of this trick, you can implement vertical menus to your heart's desire. There is some call for having a vertical menu with the same background color as the menu itself. How can I define the end of a menu selection if there is to be no apparant change in background color? Time to reflect a little. A space or blank character presents the background color. A character <Alt>+2,1,9 presents a space or blank character in foreground color, in effect swapping the background for the foreground color. By now you probably see the possibilities. At the right edge of the menu where you want the scroll bar to end, place a column of character 219 with a same foreground color as the surrounding background color. The background color can be anything: it won't show anyway. Now the bars work as intended. There is one shortcoming though: when viewed in a monochrome display, that column of characters 219 might show as a black line. In general, unless I am trying to give a presentation the look and feel of some other program, I prefer to delineate menus from the rest of the screen with lines and/or color changes. But then -- in a MakeDemo presentation, menus need not be whole screens unto themselves. Instead, I can draw the viewer's attention to the idea of the screen and veil a menu as a window to other areas in the presentation for further invesatigation. Menu Mechanics: Here is a typical menu designation. It names the screen "MENU" and contains six menu selection. Note each line is prefixed with <Alt+4>. Some printers are unable to print this character directly. MENU,ITEM1,ITEM2,ITEM3,ITEM4 ,ITEM5,ITEM6 MENU - is the name of the screen. It is only necessary to give the screen a name if it is to be called from another menu. ITEM1 - is the first menu selection. ITEM2 - is the second menu selection. ...and so on. A screen should never be given a name unless it its to be assessed from another menu. Here's the rational. MSHOW allows the user to <PageDown> to adjacent screens if and only if that screen has no name or if that name is prefixed with a "+" or "-". If you wish to let your users view your document as a presentation (ie. automatically present screens in menu order) and automatically recycle indefinitely, or until <Esc> is pressed, name the last screen, "-", and the screen to return to name "+". For example, if you want a repeating presentation to restart with screen 4, name screen 4 "+". And of course, name the last screen of the last menu selection "-". And now you can include DOS Commands in your Menus: MakeDemo now gives you the ability to create a DOS menu shell of sorts, by defining menu selections to perform commands at the DOS level without first exiting your presentation. For example, you might wish to include the DOS DIR command as a menu selection, or let your user execute another program, then return to your presentation. Just prefix the name of the DOS command with a '&', as in "&DIR=D" if you want to use a "D" for a "hot" key. That's all there is to it. Run BAT files or EXE or COM executibles right from within your presentation. There's a lot you can design into your presentation. When <PagingUp> MSHOW lets you go no further back than a screen with a name. It shouldn't be too hard to visualize that a sequence of screens can be made inaccessible simply by giving the first of the sequence a name and then NOT including that name in any of your menus. The screen name, in this case "MENU", indicates that this screen, in addition to having a menu of its own, is to be accessed only from another menu screen. MSHOW recognizes hot keys and/or function keys that you so designate as part of your menu. To use this feature you include the designator with the menu selection above. For example, if we change menu item 1 to "ITEM1=B-FF6", then pressing the 'B' key or the 'F6' function key will also cause item 1 to be selected. A more realistic selection might be "SHELL=S-FF6". If you layout the menu screen with the "S" for "SHELL" bright white and the rest of the letters the subdued while or grey, right away the user intuitively knows that pressing the "S" key will cause "SHELL" to activate. All the keys of the alphabet are permitted as well as all the Function Keys, Control / Function keys, Shift / Function Keys, and Alternate / Function keys. The following is a list of the possibilities. FF1 through FF10 CF1 through CF10 SF1 through SF10 AF1 through AF10 You can designate a hot key with a different foreground color for that key in your actual menu selection. IMPORTANT NOTE: The equal "=" sign must precede the "hot" key, the "-" must precede the function key designation. Failure to respect this constraint will appear as non working or unwanted key assignments. For example, the following example should clarify things. Here is a menu selection of 4 rows of 20 characters each. The 'x' designates different foreground / background colors from those of the surrounding area. <Alt+6> xxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxx You can place selections anywhere on the screen, put them in list boxes or in bars like those of MakeDemo. Or you can imbed them in text to make certain words "hot." Think of menus as a tree with branches. Start at the base of the tree (DOS) and climb up into the tree and trace your steps as you explore out to a leaf. You probably won't give your viewers as many choices as they explore your "tree," but the concept is similar. With MakeDemo the branches can vary in length, which is to say that you can show a number of screens before coming to the next named screen for another menu selection defined elsewhere. MSHOW lets your viewer progress through a series of screens until the next screen has a name defined. Normally MakeDemo restricts the viewer from traversing backwards through the presentation only until he or she comes to a screen with a label on it. You remember: a "label" is used by the menu to know which screen to present when a menu selection is made. Trying to progress further returns the viewer to menu from whence he or she came. Except... There might be times when you might allow the viewer to move into the next menu selected series of screens without first returning to a menu. For example, if you are putting together a catalog with a "Table of Contents," you might just as well let the viewer roam around in the general area without forcing a return to the "menu," before moving on. Those screens must have names starting with a '+'. For example, suppose screens are arranged as follows: Screen Label Choices 1 2 <ALT+4>+MENU,GOTO1,GOTO2 <ALT+6>GOTO1 <ALT+6>GOTO2 3 <ALT+4>HLLP 4 5 6 <ALT+4>GOTO1 7 8 9 <ALT+4>GOTO2 10 11 12 13 14 <ALT+4>-MENU This would be a organization of a typical presentation file. Here there would be a menu somewhere on screen 2 with two choices: "GOTO1" and "GOTO2." Screens 6, 7 and 8 associated with GOTO1 and screens 9 through 14 are reached by selecting GOTO2. There is only one way to get to screen 6: that is by selecting GOTO1 from screen 2. However, there is an additional way to access screen 9; that is from screen 8, but only f the screen name were prefixed by a "-" sign. Now, if all that is true, then how does one access screens 3 through 5? That's simple; just press F1. Those screens are the "Help" facility, if you choose to have one. To include "Help," the first screen must be labeled "<ALT+4>HLLP". The "Help" screens should always be placed just after a menu screen or after the last screen of a choice. In that way there is no way for the user to stumble into Help except by pressing F1. Now, you may inquire about the choice on screen 14. There are several things you can do on the last screen. We chose to use the name of screen 2, the reason being that trying to move beyond that screen either in manual or automode will cause the presentation to repeat the presentation starting with screen 2. Or I could have given it no name, in which case, the presentation would wait there indefinitely for someone to press <Esc>, which would precipitate a return to DOS. There is one other nuance having to do with menus that you might have missed in viewing the presentation. For the sequence of screens shown above, you might have wondered what would happen when MakeDemo presented a menu while in the "auto" mode. Well, MSHOW would assume that you want to sequentially go through the menu and present every branch out to each leaf, return to the menu and follow the next branch, and so on. There might be a situation where you would like your viewer to be in automatic mode, but then stop at a menu screen and wait indefinitely for a key press. To do that merely precede the name of the menu screen with a question mark, "?". MakeDemo leaves it up to you as to how you wish your viewers to use your presentation. Types of Screens: As you might have surmised from viewing one of the presentations supplied with this package, MSHOW interprets each screen before presenting it. A screen is presented either in whole (completely replacing the previous screen) or various rectangular shaped portions of the next screen "overlay" their respective segment of what's already on the screen. For the most part, you the creator of the presentation determine how a screen is designed and how it is to be presented. For example, the first half dozen or so choices from which to choose on the "Appearance" menu (when working on a screen from within MDEMO) are whole screen "overlays" if you will. The rest are called "segments." Strictly speaking, menu screens are show in segments, regardless of the "appearance" mode selected. We will get to that a little further on. How does MSHOW know a "segment" from a whole screen, you ask? A blank screen (black background with characters, if any, of a dull foreground color appears transparent when presented by one of the "segment" modes. To get the attention of MSHOW for presentation, that portion of the screen with bright foreground on a black background or any foreground on any background other than black will appear. MSHOW finds those segments by searching each row top to bottom looking for the first color combination described above. Defining that point as the upper left corner of the segment, MSHOW then travels that row looking for the first instance of a change in background color, defining it as the segment's upper right corner. MSHOW then moves back to the upper left corner and scans down this first column looking for a change in foreground or background color to determine the height to then calculate the bottom right and bottom left segment corners. After presenting a segment, MSHOW then repeats the process finding and presenting all the other screen segments, left to right, top to bottom in that order. IMPORTANT NOTE: The procedure MSHOW follows to define segment corners differs from that of defining the corners of menu selections. For segments the top and left edges solely define the designated area; for menu selections, the top and right edges solely define their respectful areas. Don't confuse the two. Here's the rational. Segments such as "windows" type boxes with highlighted edges to simulate sloping edges frequently use the same colors for the top and left edges. Menus, on the other hand, need the blank space at the end rather than at the beginning of a line to hide the key to its width. How does MSHOW present a "whole" screen (i.e. one that was intended for showing in segments) that is given one of the "segment" appearance modes? That depends. If the edges of the screen have the same background and foreground color, no problem. A quick way to determine that (when in MDEMO) is to select "Pick & Place" and then "Screen Test." Diamond symbols appear at each character location, making a visual check very easy. What happens if the edges are not of the same foreground/background colors? MSHOW starts with the upper left edge of the screen and scans to the right looking for a change in background color, and so on. The results are usually not what you intended. "Screen test" all screens and correct any problems before viewing a series of screens with MSHOW. After you have worked on a screen for a while, the amount of various foreground colors on a blank sections of screen will surprise you. And what's more, that carelessness will increase the size of your presentation file, conceivably by up to 20 percent. As I mentioned before, "menu" screens come up after MSHOW finds what it perceives as the first segment. MSHOW does not look further for more on menu screens. On the system menu screen more segments are allowed that can be accessed by the viewer pressing function key F1 for help. That's the only exception. So you want to be particularly careful with menu screens; lest some blank segment gets presented: and nothing seems to appear. The foregoing discussion also applies the "Prompt" screens discussed next. "PROMPT" Screen There is one situation whereby you might wish to prompt your user with a question and wait for an answer before proceeding. For example, before sending something to a printer, you might give your user instructions and a chance to abort the process before continuing. The screen name "PROMPT" is reserved for such an event. The screen is defined with <Alt+4> PROMPT,,,, and the screen is layed out with 5 selections, the first three designated for information display, the last two for possible answers. For example <Alt+6> xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx <Alt+6> xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx <Alt+6> xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx <Alt+6> Yes <Alt+6> No The same rules apply here as for menu selection. And then somewhere on this screen is the information to be used when a prompt message is to be displayed. For example, 9,Order Form is Next,Prepare Printer,Continue ?,YES=Y,NO=N,1 The first character, in this case, the '9' is sacrosanct as well as the 'YES' and the 'NO'. The rest of the prompt line can be anything. The three character strings appearing after the '9' separated by ',' can be anything you like to be displayed centered on the three lines. The individual strings can be any length, but total length of the line can not exceed 80 characters and must start at the left edge of the screen. And last but not least, the last character, here a "1" is the default if neither of the selections is selected: a "1" indicates a YES, a "0" indicates a NO. Be Mouse Ready: Certain screen areas are "hot," namely the edges: top, bottom, left, and right. pushing the mouse to an edge causes MSHOW to look for a system menu screen named "TSIDE0", "BSIDE0", "LSIDE0", "RSIDE0", representing top, bottom, left and right edges respectively. If one of these screens exist, the menu is presented as discussed previously. Usually such a screen is constructed of two segments: the menu and its context sensitive help. To work properly, the menu must be positioned such that MSHOW finds it first before finding the "help" segment. Remember, MSHOW searches a screen left to right, top to bottom, to find a segment to display. With this scheme it is not possible to place a menu across the bottom of the screen with the "Help" segment above it. The menu must be found first. _____________________________________ VI. Create a Presentation with MDEMO Upon typing MDEMO at the DOS prompt and RETURN, the screen goes blank and a menu appears across the bottom of the screen. This is screen # 1 of an as yet to be named file. It happens to be a blank screen because you have not yet done anything to improve its looks. However, there are things you can do. You can "Edit" it by selecting "Edit." You can create a box and "Place" it anywhere on the screen. When you're finished doing either of the above, press <Esc> and you will be asked whether you wish to save the screen, and if so, name the file that will become the presentation you are working on. From that point on you can perform a number of other operations upon that screen: like choosing the "More" menu selection to see the other half of the menu and then duplicating the screen or inserting a blank screen, to name two. Or, upon startup, you could select "Files" and "Fetch" a file that you previously worked on. Or, if you are already working on a file, choose "Files" again to suspend operations in the work-in-process in order to look at another file with the possible goal of inserting one or more screens from it into the work-in-process. Or you could look at previously "captured" screens and insert them where desired. Or you can <PgDn> and <PgUp> through an ASCII text file and import any sequence of 25 line chunks. Before we go on; we assume that you have digested the "Help" file, "MDEMO.HLP". You saw them when you ran "DEMO.BAT." Or if you have dabbled with creating a presentation or two and have pressed F1, you got to the same file. It's important that you spend some time viewing this presentation before going any further in this manual. There's little sense duplicating some of the same information here when viewing it as a presentation is so much more satisfying. Go on: fetch a presentation, move through the screens with a mouse or arrow keys and then "Save" it. Now you can save some of the screens to a new file and then work on them separately. Or you can save a screen to disk and "Fetch" it later into another file or the same file but in a different place in the sequence of screens. When working on a file, MDEMO handles screens just like a word processor handles pages, except shuffling screens is a little easier than shuffling pages. Changing the order of screens can only be done by swapping adjacent screens. You can walk a screen to a new location, but if the number of screens to bypass is great, you might better "Save" the screen and then "Fetch" it at the desired location. Don't forget to go back and delete the screen at its original location. For ease in handling, anticipate the presentation you wish to create and try to break it down into a number of modules: something along the lines of how you might define a number of menu selections. Work on these individually and when you are finished with the pieces, combine them for the final result. MDEMO Features: MDEMO has a number of features that make it easy for you to create stunning screens with a minimum of effort. Not only can you edit anywhere on the screen, "Window" gives you the capability to outline portion of the screen and, in effect, "capture" that portion for editing. Turn on the "word-wrap" feature by pressing <Insert>. You can "Recolor" that portion with the F3 and F4 function keys, you can make a "Copy" of it, or "Erase" it or "Move" it and "Place" it somewhere else on that screen or another. And you can resize the window by moving the lower right corner using the <Ctrl> up arrow, down arrow, PgUp, and PgDn keys. Remember to always "Place" a box you have created or a portion of a screen that you have copied or moved before pressing <Escape> to return to the main menu. In the event that you press <Esc> without first "placing," in answer to the question, "Save Screen?", answer "No." and try again. When you want to "place" a segment on another screen, as long as the segment has not been "erased" in memory, it can still be "placed." Using a Mouse: MDEMO is mouse aware; ie., if the mouse is NOT positioned in the upper left corner of the screen. If the mouse is anywhere else, it is active. Pass it over a menu selection and watch that selection become highlighted. Using a mouse really speeds things up. If you don't have one, seriously think of getting one. Whereas some programs let you move a mouse anywhere on the screen with no apparent effect other than seeing the mouse cursor move, MakeDemo immediately shows you "hot" areas of the screen: you'll see the background and foreground color change when the mouse passes over it. If you see what looks like a menu, simply move the mouse to a what looks like a selection and see if its colors change. If it's a selection you wish to make, merely click the left mouse button. Still, for those without a mouse, when a menu appears on the screen, one of the selections is already highlighted. You can use the arrow keys to maneuver through the various choices and pressing <Enter> while highlighting a particular one, selects that one. Backing out takes a few more words to explain. Whether using a mouse or not, pressing <Esc> any time causes one to step back up through the menu tree and eventually out to DOS with possibly some questions to answer (MDEMO only) before allowing further retreat. But the mouse works a little differently whether you are using MakeDemo or viewing a presentation outside of MakeDemo. If within MakeDemo, moving the mouse off a possible selection and clicking the left button does the same thing as pressing the <Escape> key. If viewing a presentation, such action is ignored. Instead, you must move the mouse right to display the "mouse bar" on the right edge and move it to the "Quit" row and then click the left button. You might ask, "Should I use the mouse in preference to the arrow keys?" Our experience indicates that using both can really speed things up. The trick we use here at WindhamWoods Publishing in making presentations is to primarily use the mouse with the right hand to block segments of the screen for moving and copying etc., and with the left hand, be ready to press the appropriate first letter of the command or menu selection for what we want to do with it. Even if you have chosen to hide the menu bars on the bottom lines of the screen, the selections still work. It saves steps later after you know the more commonly used keys. You might want to temporarily disable the mouse when you're moving or copying a segment around on the screen. Remember to move the mouse to the screen's upper left corner. When using the mouse to move "pick & place" segments around on the screen, note that the segment tries to adjust itself so that its lower right corner aligns with the mouse. This is not always possible, especially when the segment is wide, and then the mouse appears to have no effect. Just be aware. Clicking the left button once anchors the box temporarily and brings up a second menu on the next to bottom line of the screen. It is not necessary to see this menu to use it. Once you know what selections are available you can select one directly by pressing the appropriate capitalized letter for that selection. Large Fonts: After selecting "Edit" you can then select "Fonts" by pressing the function key, F10. You will be presented with a window displaying a word in one of the many fonts that are available. Press <Return> to select the displayed font; any other key will display the same word in another font. Continually pressing a key other than <Return> will cycle through all the available fonts. Using any of the large fonts is somewhat crude. For simple tasks like making titles, etc., they work fine. However, don't expect to be able to word wrap. In using large fonts, it's best to get what you want on each line and then use "Pick & Place" to move a screen segment into final position, etc. When you are finished using a large font, one press of <Escape> first gets you back to normal font; a second press gets you out of the "Edit" mode. PLEASE NOTE: The fonts are contained in FONTS.WWP, an ASCII file that you can add to or modify to your own wishes. The system is pretty easy to figure out. Just be consistent. Appearance Modes: There are three aspects to presenting a screen. First is the method such as simulated blinds or sprinkling. There are over 20 choices: some for the entire screen, some for overlays where only a portion of the screen is updated. A second aspect is "sound." Some of the methods have a built in sound effect unique to that method. In general, it's best to forgo the sound effects except where you desire to emphasize a particularly strong point. They wear pretty thin after hearing them a few times. And lastly, there is the duration with 5 choices available. To define the appearance options, they can be accessed by selecting "More" at the main menu and then selecting "Appearance." Overlays, the Key to Presentation Effects. A screen of 25 rows by 80 columns has room for 2000 characters. However, a screen character also has color information. For each character there exists a color attribute "character" defining the background and foreground color. Therefore, a screen commandeers 4000 bytes, of character space in memory or on disk. There are 8 background (all low intensity) colors and 16 foreground (the same 8 low intensity and 8 new high intensity) colors. MakeDemo makes the assumption that no presentation segment will use a low intensity foreground color on a black background. It really looks pretty drab. But that is not strictly true. As long as a segment box has a top and left edge of a high intensity foreground on any background, MSHOW will recognize the rectangle so defined as a segment and deal with it accordingly. Just use spaces for the top row and left column. The foreground color is only used for characters. MakeDemo finds the height and width of a segment, as we discussed before, by first finding the upper left corner of a segment, remembering the color attribute of that spot, and "looking" along the top row from left to right for a change in the color attribute or the screen edge, whichever comes first. In like manner, MakeDemo "looks" down the left edge to find the bottom row. Consequently, you can place segments, as defined by their upper and left edges, anywhere on the screen and MSHOW will be able to find and display them. Stack them or place them side by side. MSHOW looks for the upper left corner of segments, first from left to right, then top to bottom. Put a "bright" top and left edge on a screen and the screen becomes one segment. Then use one of the display methods that are designed for use with segments, such as scrolling and sliding. Screen Test: Screen Test is very powerful for looking at a screen as MSHOW sees it for presentation, especially if you select one of the overlay or "segment" modes for displaying that screen. It is only available from the "Pick & Place" menu. It is a momentary display of the screen showing 25 rows of 80 diamond in place of each character, spaces or otherwise. The foreground/background color of each character is the important thing to look at. Remember, screen segments for overlays and menu selections rely on being surrounded by different colors and/or dull colored diamonds on a black background. Use screen test to check the screen. Almost always, when a screen doesn't appear as designed, it's because MSHOW doesn't ghet the right clue as to where a segment's corners are located or where a menu selection highlight ends. Because screens are compressed before saving, "Screen Test" is indespensible in minimizing the size of the screen as saved in the file. In brief, as the screen is compressed, first and foremost all the color attributes for each character is put through a form of run length encoding. Basically, each time the color attribute changes the length of a screen record increases by three bytes. After working on a screen using "Pick & Place," moving a few things around, erasing something, etc., the screen might be what you want, but the color attibute for spaces can be anything but one color, preferably dull green on a black background. From "Pick & Place" it's an easy step to do a "Screen Test", move the corners to the area in question and "Blank" that section or recolor it to your desires, then recheck again with "Screen Test." Viewing a Work-in-Process: MDEMO gives you the ability to shell out to DOS. Once at DOS again you run any program including MSHOW to view your work-in-process. MSHOW.EXE is the file that presents your creation(s). This one file can be used in stand alone fashion to present any number of your creations, as in MSHOW MYDEMO or MSHOW THISDEMO or MSHOW THATDEMO for viewing. When finished, remember to type EXIT and <Return> to get back to your MDEMO session. Incidently, MSHOW has the capability for shelling out to DOS should you choose to make it available to your viewers. Or, as discussed in the next section, you can combine YOURDEMO with MSHOW.EXE using WWP_MAKE.EXE to create a single executable file. For uploading and downloading over BBSs this makes the most sense. __________________________________________ VII. Making Single .EXE file Presentations Any MakeDemo file can be made into its own .EXE file. But there are a few restrictions. First of all, the number of screens in a file can not exceed 2000. And second, if you want to include your own "Help," it must be part of the same file. I suppose that goes without saying. MSHOW.EXE serves two purposes. It can be used as is to present an MDEMO created file. And it also is the basis for making those smaller single .EXE file presentations. The utility WWP_MAKE.EXE does the work for you, by combining the necessary elements into one file. The command line must include two arguments and, optionally, a third. MYDEMO.EXE, if it already exists, will be replaced with the new. The file names for the two arguments are arbitrary; use any names you like. If WWP_MAKE can not find the file specified by the second argument, it terminates and returns to DOS. C:\MDEMO> WWP_MAKE MYDEMO.EXE PRESENT.MD4 1234567,ABCD ---------- |_ _ _ _ _ |------------ | |Presenting| Branding | | File | Info | |_ _ _ _ _ | | | | | +- - - - - -+ | _ _ _ _| | | | | | | | MSHOW.EXE | | | | | | | | | +- - - - - -+ | | | | +- - - - - - - -+ | | | MYDEMO.EXE | | |_ _ _ | Single | _ _ _ _ _ _ _| | File | +- - - - - - - -+ WWP_MAKE combines MSHOW.EXE, your presentation file, and its associated index file into one .EXE file: everything in one file. However, the index file must exist first for WWP_MAKE to complete its task. Remember, MSHOW automatically creates the index file if it doesn't exist when viewing a presentation with MSHOW.EXE. The point is: be sure to run a presentation through MSHOW before making the .EXE executible. WWP_MAKE also includes a "work around" for a potential problem with machines using DOS versions prior to 3.0. Let me explain. With the advent of 3.0, a single file executable can determine its own file name, while executing, and open itself a second time to access the appended presentation. To enable your presentations to function on machines using prior versions of DOS, MSHOW looks for the file name hard-coded into the EXE composite file. If you were to "debug" such a file, you would discover its name imbedded in the code. A subtle consequence of this "trick" is that your final creation will only work with DOS versions prior to 3.0 PROVIDED that you DO NOT CHANGE the name of the executable file after you have created it. It will not work if RENamed. Branding In addition, you have the option of branding your final creation so that, should your viewer not use the correct validation code which you assign, any 'shareware' screens in your presentation will be activated. Your creation will not be crippled in any way. Any screen with the name "NAG" will be shown just like any other. You can put anything on it that you like. In fact you can include more than one NAG screen placed strategically in your file, as long as each screen has the name "NAG". Note the third argument in the syntax for using WWP_MAKE.EXE. Here you should replace the number '1234567' with some other number known only to you. That number seeds a quasi random number generator. You can use any seven digit number above 1000000, or one million; followed by a comma, with no spaces; followed by a four digit serial number greater than 1000 to replace, ABCD, which you can choose to your liking. To find the corresponding password for a unique serial number, KEY.EXE has been included. The syntax for using KEY.EXE is KEY 1234567 where 1234567 is the same seed number discussed above. KEY will then ask for the serial number you imbedded in your executable file and will display its corresponding password. For example, if (as we did in DEMO.BAT) you use the seed number, 1234567, and assign a serial number of 1000, then using the utility, KEY.EXE, you would calculate the validation code to be '2236'. ________________________________________________ VIII. MLITE, The MakeDemo Stripped Down Runtime Registered users have requested a MakeDemo runtime that takes up as little disk space as possible while still providing the minimum in functionality. MLITE.EXE weighs in at a little over 13 k Bytes. It's sole function is to show a series of screens (i.e. full screens: no overlays.) There is no provision for Help at the touch of the F1 key. There is no support for either a mouse or menus. And branding is not supported as well. There are two ways to exit MLITE. The first is the <Esc> key which in addition sets the DOS ERRORLEVEL to a 1. The other is the <Return> or <Enter> key which leaves the DOS ERRORLEVEL set at 0. A presentation can be appended to the end of MLITE, just like with MSHOW, except its length can not exceed 35 k Bytes. That's about 45 screens, give or take. Seven and only seven key strokes are recognized: PgUp or Up Arrow Key Presents previous screen PgDn or Down Arrow Key Presents next screen F5 Toggles between monochrome and color Return or Enter Presents next screen, if it exists, or exits with DOS ERRORLEVEL = 0 Esc Exits with DOS ERRORLEVEL = 1 MLITE is useful for making a front end for other software where a few expository screens would help get the novice users off to a good start. For example, you might want to take a look at START.BAT. We've used it as a way to start MDEMO with a few start-up screens that experienced users can later avoid by calling MDEMO directly from the command line. To those of us in the shareware business, especially ASP members, now we can present a more elaborate shareware message to first time users without mucking up the programs themselves with allocated, but never used again, memory. Disk vendors can now incorporate a small front end on all the disks they distribute. You'll note that START.BAT uses MLITE.EXE with a command line argument: namely the name of the file to present, MESSAGE.1ST. I could have used WWP_MAKE to combine the two into an .EXE file, but I left them separate to minimize the size of the archive. IMPORTANT NOTE: WWP_MAKE expects to append the presentation file to a copy of MSHOW.EXE to produce the final .EXE file. Therefore, if you wish to fool WWP_MAKE into using MLITE.EXE instead, you must REName it to something like MSHOW1.EXE, COPY MLITE.EXE to MSHOW.EXE, run WWP_MAKE, and then REName MSHOW1.EXE to MSHOW.EXE. To automate this process, you might consider writing two batch files and place them in the directory with all the MakeDemo files. Here are the two listings: REM GO_MLITE.BAT COPY MSHOW.EXE MSHOW1.EXE COPY MLITE.EXE MSHOW.EXE and REM GO_MSHOW.BAT COPY MSHOW1.EXE MSHOW.EXE With the MakeDemo directory listed in your "PATH" statement of your AUTOEXEC.BAT file, you can make the switch while working in any other directory. _________________________ IX. MDEMO Quick Reference Function Keys F1 - Help F2 - MakeDemo Logo F3 - Background Color F4 - Foreground Color F5 - Color/ Monochrome F6 - Print (normally off) F7 - (not used) F8 - Grab Color F9 - Menu (normally on) F10 - Fonts ( Edit only) Pick & Place / Box / Recolor Move Box Horizontal Left or Right Arrow Keys Vertical Up or Down Arrow Keys Mouse Mouse controls lower right corner. Box follows. Resize Box Horz. <Ctrl> + Left or Right Arrow Keys Vert. <Ctrl> + <PgUp> or <PgDn> Keys Mouse HOLD DOWN Right Button. Anchors Upper Left Corner. Drag Mouse to Change Size. Release Right Button. Copy Save segment to memory, leaving screen intact. Move Same as "Copy" plus erase blocked screen area. Erase Erase saved screen segment kept in memory. Blank Erase blocked screen segment. Place Replace screen segment with that now visible. ___________________ X. Customer Support WindhamWoods Publishing is a small software company owned and operated by Warren Munroe. At WindhamWoods Publishing we believe that the PRIMARY purpose of business is service, not profit. This concept is fundamental to our approach to product development, production and marketing. WindhamWoods Publishing has been producing top quality computer software at reasonable prices, continuously, since 1989. Please feel free to contact me (Warren Munroe) at any time if you have any questions, comments or suggestions. I can be reached by mail, phone, or Compuserve: Warren Munroe Phone: 603.893.2667 WindhamWoods Publishing Orders & Tech Support 603.893.2667 P. O. Box 314 CompuServe 72260,1700 Windham, NH 03087 U.S.A.